【第298期】关于前端开发谈谈单元测试上篇

来自早读君：

这篇来源于团队负责某app里webApp页的感想，主要有两个：

1:这个页面集合太多的产品功能需求，而这些需求都是灵感一现的，没有太多的梳理。判断条件分之太多。

2:负责这个页面的开发童鞋，包括前端都换了好几波人了，导致接手的童鞋很难理解（注释的不是那么清楚）

现在想迁移跟重构，导致难度加大了，所以才萌生前端单元测试的想法。

今天分享的这篇算是了解，技术普及文～～

正文从这开始～

单元测试Unit Test

很早就知道单元测试这样一个概念，但直到几个月前，我真正开始接触和使用它。究竟什么是单元测试？我想也许很多使用了很久的人也不一定能描述的十分清楚，所以写了这篇文章来尝试描述它的特征和原则，以帮助更多人。

什么是单元测试？

先来看看单元测试的定义，在维基百科英文版中可以找到KolawaAdam在 AutomatedDefect Prevention: Best Practices in Software Management 一书中对单元测试的定义：

重点在于最后，单元测试的目的显而易见，用来确定是否适合使用。而测试的方法则包括控制数据，使用和操作过程。那么以我的理解，每个单元测试就是一段用于测试一个模块或接口是否能达到预期结果的代码。开发人员需要使用代码来定义一个可用的衡量标准，并且可以快速检验。

很快我发现有一个误区，许多人认为单元测试必须是一个runner集中运行所有单元的测试，并一目了然。不，这仅仅是一种自动化单元测试的最佳实践，在一些小型项目中单元测试可能仅仅是一组去除其他特性的接口调用。甚至在一些图形处理或布局的项目中单元测试可以结合自身特性变的十分有趣，比如Masonry，一个网格布局库，在它的单元测试中不是一个红或绿的条目，而是一行一行的小格布局用以说明布局被完成的事实，这样比代码检查布局是否正确再以颜色显示结果来得更直观高效，也避免了测试程序本身的bug导致的失误。

打个比方，单元测试就像一把尺子，当测量的对象是一个曲面时，也许可以花费大力气去将它抽象成平面，但我更提倡量身定做一把弯曲的尺子去适应这个曲面。无论怎样，单元测试是为了生产代码而写，它应当足够的自由奔放，去适应各种各样的生产代码。

为什么要单元测试？

也许定义中已经很清楚的指明了其意义，确认某段代码或模块或接口是否适合使用，但我想会有更多的人认为，直接在测试环境中使用软件可以更加确保软件是否可用。不，在实际使用过程中会伴随着一大批的附带操作大量增加测试时间，并且无法保证其测试覆盖率。所以我认为单元测试的目的并不仅仅是确认是否可用，而是更高效更稳定的确认其是否可用。

随着项目规模的增加，函数、方法、变量都在递增，尤其是进度的不足，来自产品经理的压力，还有QA所带来的各种Bug报告会让原本整洁的代码变得一片混乱。我甚至见过同一个接口以不同的名称出现在8个不同的控制器中。这时也许我们首先想到的是重构，可是等等，在重构结束时我们如何确定项目仅仅是被重构了，而不是被改写了？此时单元测试将是一根救命稻草，它是一个衡量标准，告诉开发人员这么做是否将改变结果。

不仅仅是这样。许多人认为单元测试，甚至整个测试都是在编码结束后的一道工序，而修复bug也不过是在做垃圾掩埋一类的工作。但测试应该伴随整个编码或软件周期进行，还有将在后面提到的TDD这样有趣的东西，单元测试将超前于编码。我的意思是，单元测试应该是一个框架、标准，经常被形容被脚手架，像建筑一样，脚手架的高度至少应该和大楼高度不相上下，甚至一开始就搭好脚手架。

如何做单元测试？

弄清了单元测试的目的和意义，但如何开始？很简单，首先它是一个检验，所以应该只有pass或fail两种情况。而检验的对象应该是某个接口或模块，所以应该调用它获得一个结果。检验这个结果就是单元测试的基本动作，就拿一个除法函数来做例子：

显然，将会提示pass通过。但是问题来了，这个测试的用例太单一和普通了，如果使用0做除数呢？是NaN？还是Infinity？或者在实际使用时，产品需要一个0来代替这样一个不符合数学概念的结果去适应必须为数字类型的某种计算，于是division出现了一个bug。另外当覆盖率增加，也意味着用例的增加，我们需要把if条件语句提出来做成一个函数多次调用。还有alert方法，如果用例太多，我相信你会点确认点到手软，也许可以直接显示在页面上。

所以我添加了一个关于除数为0的用例，并重构了代码：

现在可以使用matcher方法添加许多测试用例，并且还能为该用例命名，在页面中直接显示每个用例是否通过。这样一个基本的单元测试就完成了，当然它的覆盖率还远远不够，这里仅作为一个例子。另外为了提高效率还应该使用颜色来标记是否通过，可以一目了然。

测试驱动开发

TDD是Test Driven Development 的缩写，也就是测试驱动开发。

通常传统软件工程将测试描述为软件生命周期的一个环节，并且是在编码之后。但敏捷开发大师Kent Beck在2003年出版了TestDriven Development By Example 一书，从而确立了测试驱动开发这个领域。

TDD需要遵循如下规则：

1)写一个单元测试去描述程序的一个方面。

2)运行它应该会失败，因为程序还缺少这个特性。

3)为这个程序添加一些尽可能简单的代码保证测试通过。

4)重构这部分代码，直到代码没有重复、代码责任清晰并且结构简单。

5)持续重复这样做，积累代码。

另外，衡量是否使用了TDD的一个重要标准是测试对代码的覆盖率，覆盖率在80%以下说明一个团队没有充分掌握TDD，当然高覆盖率也不能说一定使用了TDD，这仅仅是一个参考指标。

在我看来，TDD是一种开发技术，而非测试技术，所以它对于代码构建的意义远大于代码测试。也许最终的代码和先开发再测试写的测试代码基本一致，但它们仍然是有很大不同的。TDD具有很强的目的性，在直接结果的指导下开发生产代码，然后不断围绕这个目标去改进代码，其优势是高效和去冗余的。所以其特点应该是由需求得出测试，由测试代码得出生产代码。打个比方就像是自行车的两个轮子，虽然都是在向同一个方向转动，但是后轮是施力的，带动车子向前，而前轮是受力的，被向前的车子带动而转。

行为驱动开发

所谓的BDD行为驱动开发，即Behaviour Driven Development，是一种新的敏捷开发方法。它更趋向于需求，需要共同利益者的参与，强调用户故事（User Story）和行为。2009年，在伦敦发表的“敏捷规格，BDD和极限测试交流”[3]中，Dan North对BDD给出了如下定义：

BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。

另外最主观的区别就是用词，‘example’取代了‘test’，‘describe’取代了‘class’，‘behaviour’取代了‘method’等等。这正是其特征之一，自然语言的加入，使得非程序人员也能参与到测试用例的编写中来，也大大降低了客户、用户、项目管理者与开发者之间来回翻译的成本。

简单来说，我认为BDD更加注重业务需求而不是技术，虽然看起来BDD确实是比ATDD做的更好，但这是一种误导，这仅仅是就某种环境下而言的。而且以国内的现状来看TDD要比BDD更适合，因为它不需要所有人员的理解和加入。

来自早读君：

今天上篇先普及下，虽然单元测试很好听，但实际的有多少人去写这个单元测试，还是值得思考的。可能还没触碰到痛点吧。明天继续分享写单元测试的框架～

长按图片识别图中二维码